Telegram Group & Telegram Channel
Необычный вопрос на собеседовании

Искали мы как-то человека в команду. Пришел кандидат, обсудили опыт, прошлись по основным вопросам.

Дошли до многопоточки. Человек сказал, что нужно ее избегать, потому что тема сложная и легко ошибиться. А потом добавил:

🧑‍🦰: Вот Redis однопоточный, внутри у него нет блокировок, поэтому он такой быстрый!

У меня в голове сразу возникла задача “на подумать”. Решила с вами поделиться, тк такое утверждение про Redis слышу довольно часто.

Рассмотрим два сервиса:
🍓Первый - тот самый однопоточный Redis.
🚲 Второй - key-value хранилище на базе ConcurrentHashMap и Spring MVC. Код примерно такой:
public class MapController {
   private final Map<String, Object> map = new ConcurrentHashMap<>();

   @PostMapping
   public void putValue(@RequestParam String k, @RequestParam Object v) {
      map.put(k, v);
   }

   @GetMapping
   public Object getValue(@RequestParam String k) {
      return map.get(k);
   }
}

Задача: сравнить оба варианта. В расчет берём только базовую функцию - записать и прочитать ключ-значение из оперативной памяти.

В итоге получился очень интересный разговор. Люблю такое на собеседованиях😊

Ещё немного вводных, чтобы глубже погрузиться в вопрос.

Структура данных

В Redis используется простая хэш-таблица. Считаем хэш ключа, определяем бакет, добавляем в список. Алгоритм даже проще, чем в джаве. В джаве список перестраивается в дерево, когда элементов много. В Redis такого нет.

Многопоточный доступ

В Redis хэш-таблица никак не синхронизирована, безопасно работать может только один поток.

ConcurrentHashMap не зря называется concurrent. Область синхронизации при записи ограничена одним бакетом, т.е число одновременно пишущих потоков ~ числу бакетов. На чтение ограничений вообще нет.

Потенциально ConcurrentHashMap способен обслужить миллионы запросов одновременно. Redis в каждый момент времени работает с одним запросом.

Явный перевес в сторону нашего велосипеда🧐

На этом этапе кандидат согласился, что всё очень загадочно. И фраза, что Redis однопоточный и потому такой быстрый, звучит странно.

Почему же считается, что Redis лучше, и как он справляется с нагрузкой своим одним потоком? Об этом расскажу завтра❤️



tg-me.com/java_fillthegaps/611
Create:
Last Update:

Необычный вопрос на собеседовании

Искали мы как-то человека в команду. Пришел кандидат, обсудили опыт, прошлись по основным вопросам.

Дошли до многопоточки. Человек сказал, что нужно ее избегать, потому что тема сложная и легко ошибиться. А потом добавил:

🧑‍🦰: Вот Redis однопоточный, внутри у него нет блокировок, поэтому он такой быстрый!

У меня в голове сразу возникла задача “на подумать”. Решила с вами поделиться, тк такое утверждение про Redis слышу довольно часто.

Рассмотрим два сервиса:
🍓Первый - тот самый однопоточный Redis.
🚲 Второй - key-value хранилище на базе ConcurrentHashMap и Spring MVC. Код примерно такой:

public class MapController {
   private final Map<String, Object> map = new ConcurrentHashMap<>();

   @PostMapping
   public void putValue(@RequestParam String k, @RequestParam Object v) {
      map.put(k, v);
   }

   @GetMapping
   public Object getValue(@RequestParam String k) {
      return map.get(k);
   }
}

Задача: сравнить оба варианта. В расчет берём только базовую функцию - записать и прочитать ключ-значение из оперативной памяти.

В итоге получился очень интересный разговор. Люблю такое на собеседованиях😊

Ещё немного вводных, чтобы глубже погрузиться в вопрос.

Структура данных

В Redis используется простая хэш-таблица. Считаем хэш ключа, определяем бакет, добавляем в список. Алгоритм даже проще, чем в джаве. В джаве список перестраивается в дерево, когда элементов много. В Redis такого нет.

Многопоточный доступ

В Redis хэш-таблица никак не синхронизирована, безопасно работать может только один поток.

ConcurrentHashMap не зря называется concurrent. Область синхронизации при записи ограничена одним бакетом, т.е число одновременно пишущих потоков ~ числу бакетов. На чтение ограничений вообще нет.

Потенциально ConcurrentHashMap способен обслужить миллионы запросов одновременно. Redis в каждый момент времени работает с одним запросом.

Явный перевес в сторону нашего велосипеда🧐

На этом этапе кандидат согласился, что всё очень загадочно. И фраза, что Redis однопоточный и потому такой быстрый, звучит странно.

Почему же считается, что Redis лучше, и как он справляется с нагрузкой своим одним потоком? Об этом расскажу завтра❤️

BY Java: fill the gaps


Warning: Undefined variable $i in /var/www/tg-me/post.php on line 283

Share with your friend now:
tg-me.com/java_fillthegaps/611

View MORE
Open in Telegram


Java: fill the gaps Telegram | DID YOU KNOW?

Date: |

A Telegram spokesman declined to comment on the bond issue or the amount of the debt the company has due. The spokesman said Telegram’s equipment and bandwidth costs are growing because it has consistently posted more than 40% year-to-year growth in users.

Dump Scam in Leaked Telegram Chat

A leaked Telegram discussion by 50 so-called crypto influencers has exposed the extraordinary steps they take in order to profit on the back off unsuspecting defi investors. According to a leaked screenshot of the chat, an elaborate plan to defraud defi investors using the worthless “$Few” tokens had been hatched. $Few tokens would be airdropped to some of the influencers who in turn promoted these to unsuspecting followers on Twitter.

Java: fill the gaps from cn


Telegram Java: fill the gaps
FROM USA